In a WiMAX wireless communication system, service of multiple service flows may be provided for one user at the same time. The WiMAX allows operation requests of multiple service flows to be included in one message. In a network working group (NWG for short, which is one of the working groups of WiMAX standard organization and responsible for the work relating to network technologies of the WiMAX system) standard, a resource combination indication field may be included in a message to indicate whether operation results of multiple service flows in a same request message are bound. If multiple service flows are bound, then failure of any service flow will result in the failure of scheduled operation of all service flows in the entire request message; if the multiple service flows are not bound, then the failure of any service flow will only affect its own scheduled result; if there is no resource combination indication field, then the default is that the multiple service flows are not bound.
During a hand-off process, multiple service flows processing may be involved in one message. In the current NWG standard, the definition of a hand-off request message does not contain the resource combination indication, which may result in the loss of original service flow binding information after a mobile station (MS) executes a handoff. Under the situation that the service flow binding information is lost, if it is required to acquire the lost information again, then corresponding processing will be needed. This will increase signaling traffic.
FIG. 1 is a signaling flow chart of processing in a hand-off preparation stage during a handoff in a prior art. As shown in FIG. 1, the hand-off scenario is that (a target network) initiates authentication key (AK) context acquisition and data path pre-registration initiated by target network. FIG. 1 only illustrates the flow of a handoff to target Network 1 for easy understanding and description. It can be easily thought of that there might be a plurality of target networks in an actual process.
As shown in FIG. 1, the processing in a hand-off preparation stage may include the following steps (step 11-step 17):
step 11: an MS sends an MOB_MSHO-REQ (interface hand-off request) message to a serving ASN (current serving network) to initiate a handoff;
step 12: the serving ASN sends an HO_Req (hand-off request) message to one or a plurality of target networks; this message includes an authenticator ID and an anchor ASN GW ID (anchor network gateway ID);
step 13: target ASN 1 (target Network 1) initiates a context request flow to an authenticator ASN (authenticator network), in actual implementation, the initiation of the step 13 may be deferred to a hand-off action stage;
step 14: the target ASN 1 (target Network 1) or an anchor ASN (a network where a data management unit is located) initiates a data path pre-establishment flow, in actual implementation, the initiation of the step 14 may be deferred to a hand-off action stage;
step 15: the target ASN 1 sends an HO_Rsp (hand-off response) message to the serving ASN in response to the HO_Req;
step 16: the serving ASN sends an MOB_BSHO-RSP (interface hand-off response) message to the MS, this message includes a potential target BS (target base station) that is selected by one or a plurality of networks for the MS and can be handed off to; and
step 17: the serving ASN sends an HO_Ack (hand-off acknowledgement response) to the target ASN 1 to which the potential target BS belongs.
Further, if there was a binding relationship among multiple service flows of the MS originally, after the MS is handed off from ASN a to ASN b, the default of the ASN b will be that the multiple service flows of the MS are not bound, for the previous hand-off message did not transfer information about the binding of the multiple service flows of the MS to the ASN b, thus it is possible to result in the loss of the information about the binding of the multiple service flows of the MS after the handoff takes place.
Therefore, according to the prior art, when the MS hands off to the target network again in the ASN b, the executed processing will be the same as the processing shown in FIG. 1, the only difference is that the ASN b will be changed into corresponding serving ASN.
Further, the resource combination indication filed is not contained in the Path_Prereg_Req (path pre-registration request)/Path_Reg_Req (path registration request) message defined by the existing NWG, with regard to the operation request of multiple service flows, it can not be guaranteed that the original service flow binding information is integrally transferred after the handoff. That is not good for the optimization of the target network judging on the multiple service flows.
FIG. 2 is a signaling flow chart of processing in a hand-off action stage during a handoff in a prior art. As shown in FIG. 2, the serving ASN sends an HO_Cnf (hand-off confirm) message to the target ASN. The processing in the HO action stage may include the following steps (step 201-step 211):
step 201: according to a protocol, the MS sends an MOB_HO-IND (interface hand-off indication) message to the serving ASN to inform it that one of the target ASNs selected by the serving ASN has been handed off;
step 202: after the serving ASN receives the MOB_HO-IND message, it will send an HO_Cnf message to the target ASN selected in the previous step;
step 203: the target ASN selected above sends an HO_Ack message to the serving ASN;
step 204: if the HO_Req or the HO_Cnf message contains the authenticator ID and the authentication key (AK) context of the corresponding MS is not acquired in the previous hand-off preparation stage, then the target ASN selected above will initiate a context request flow to an authenticator ASN (a network where an authenticator is located) and requests the AK context for the MS;
step 205: if the HO_Req or HO_Cnf message contains an anchor ASN GW ID (anchor network gateway ID) field and the data path pre-registration flow has not started, then the flow may start in this step; if the data path pre-registration flow has started and SF Info (service flow information) in the Path_Prereg_Req and response messages includes data delivery trigger, then the distribution of any service flow of the MS will be triggered at once;
step 206: the MS initiates a flow of reaccessing the target ASN selected above;
step 207: the target ASN selected above initiates the data path registration flow to the anchor ASN;
step 208: after the network reaccess is completed with success, the target ASN selected above will initiate a cipher-based message authentication code key count (CMAC key count) updating flow;
step 209: after the network reaccess is completed with success, the target ASN selected above may send an HO_Complete (hand-off complete) message to the serving ASN to inform it of hand-off completion; and
step 210-211: after data paths between the anchor ASN and the target ASN selected above is established, the anchor ASN may initiate a data path deregistration flow to the old serving ASN.
So far, no technical scheme that introduces optimization processing of multiple service flows binding relationship into a hand-off process has been proposed.